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ABSTRACT 

We  diacusa  the  uae  of  a FORTRAN  precompiler  in  the  development  of  packag- 
ea  for  nonatandard  arithmetics.  In  particular,  the  uae  of  the  FORTRAN  precom- 
piler, AUGMENT,  renders  the  source  code  more  lucid,  reduces  the  number  of 
lines  of  code  in  a nonstandard  arithmetic  package,  facilitates  modification, 
and  ameliorates  the  problems  of  transporting  such  a package  to  another  host 
system. 
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SIGNIFICANCE  AND  EXPLANATION 


The  AUGMENT  precoapiler  for  FORTRAN  [7]  is  the  Boat  recent  and  most  ver- 
satile in  a series  of  FORTRAN  precompilers  which  have  been  developed  at  the 
Mathematics  Research  Center,  University  of  Wisconsin  - Madison,  over  the  past 
decade.  Originally,  the  precompiler  conoept  was  envisioned  as  a means  of 
simplifying  the  use  of  special-purpose  arithmetic  paokagea,  such  as  multiple 
precision  arithmetic  or  Interval  arithmetic,  in  the  research  environment. 

In  recent  years,  however,  AUQfBNT  has  oome  to  play  a oentral  role  in  the 
development  of  special-purpose  arithmetic  packages  as  well  as  in  their  use. 
Briefly,  one  ma7  write  the  majority  of  the  modules  of  a package  in  terms  of 
one  or  more  nonstandard  data  types,  later  using  AUGMENT  together  with  a few 
primitive  modules  to  bind  these  data  types  to  specific  representations.  This 
technique  enhances  the  clarity  of  the  code,  reduoes  the  number  of  lines  of 
code  in  the  package  (in  most  cases),  facilitates  modifications  (suoh  as  in- 
creasing precision),  and  ameliorates  the  problems  of  transporting  such  a pack- 
age to  other  host  systems. 

In  this  paper,  we  dlsouss  the  advantages  of  this  technique,  and  illus- 
trate with  examples  taken  from  the  INTERVAL  arithmetic  paokage  developed  by 
the  second  author  [19].  In  particular,  we  indloate  how  the  Interval  arithme- 
tic package  was  modified  in  the  spaoe  of  approximately  one  week  to  produce  a 
package  for  triplex  interval  arithmetic  [1],  and  we  also  dlsouss  the  nature  of 
the  modifications  that  will  be  neoessary  to  produoe  a multiple  precision  in- 
terval arithmetic  package  based  on  the  multiple  precision  arithmetic  paokage 
of  Brent  [2].  Application  of  this  technique  to  a variety  of  situations  will 
be  apparent. 


The  responsibility  for  the  wording  and  views  expressed  in  this  descriptive 
summary  lies  with  MRC,  and  , mot  .with  the  authors  of  this  report. 
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THE  AUGMENT  PRECOMPILER  AS  A TOOL  FOR  THE  DEVELOPMENT  OF 
SPECIAL  PURPOSE  ARITHMETIC  PACKAGES 

F.  D.  Crary  and  J.  M.  Yohe 


1.  Introduction 

With  decreasing  hardware  costs  and  increasing  processor  speeds,  the  cost 
of  software  development  is  becoming  more  and  more  a function  of  personnel 
cost.  Furthermore,  with  the  explosion  of  applications  of  digital  computers, 
an  ever-higher  percentage  of  users  place  implicit  trust  in  the  software  they 
use  to  support  their  applications.  Today,  a computer  system  is  regarded  by 
most  users  not  as  an  empty  box  which  must  be  programmed  to  solve  even  the  sim- 
plest problem,  but  rather  as  a hardware/software  combination  which  can  be  used 
to  solve  their  computational  problems.  Indeed,  many  users  probably  do  not 
know  — and  care  less  — where  the  hardware  leaves  off  and  the  software  be- 
gins . 

For  these  reasons,  it  is  essential  to  supply  the  user  with  reliable, 
well-documented  software  packages.  It  is  no  longer  profitable,  or  even  feasi- 
ble in  many  cases,  to  re-invent  support  software.  The  considerations  of  effi- 
ciency on  a particular  system  have  all  but  been  erased  by  the  increasing  cost 
of  highly  competent  personnel  and  the  decreasing  cost  of  hardware.  Whereas 
twenty  years  ago  code  that  wasted  machine  time  could  not  be  tolerated  for  many 
applications,  we  have  now  come  to  the  point  that  code  which  wastes  personnel 
time  can  not  be  tolerated. 

These  considerations  have  led  to  an  increasing  emphasis  on  transportable 
software.  If  development  costs  can  be  incurred  just  once  for  a package  or 
system  that  will  work  correctly  and  accurately  on  a broad  spectrum  of  equip- 
ment, users  are  willing  to  tolerate  a reasonable  amount  of  inefficiency  in  re- 
turn for  the  convenience  of  having  the  development  work  done  for  them  and  the 
confidence  that  they  can  place  in  a quality  product. 

Increasingly,  it  is  becoming  practical  to  build  on  existing  software 
rather  than  to  develop  new  package?  from  first  principles,  even  when  the  ex- 
isting software  might  not  be  just  exactly  tailored  to  the  application  in  ques- 
tion. For  example,  as  we  shall  discuss  later  in  this  paper,  it  makes  sense  to 
base  a multiple  precision  interval  arithmetic  package  on  Brent's  excellent 
multiple  precision  arithmetic  package  ([2])  rather  than  to  develop  a new  mul- 
tiple precision  package  which  Implements  the  required  directed  roundings.  The 
needed  modifications  can  be  introduced  via  a very  few  new  modules,  leaving  the 
bulk  of  Brent's  software  development  work  intact. 

In  order  to  make  the  best  use  of  existing  software,  one  must  have  the 
tools  to  make  its  incorporation  in  new  programs  reasonably  easy,  and  one  must 
adopt  a design  philosophy  which  will  make  the  use  of  both  the  tools  and  the 
existing  software  natural  and  uncomplicated. 

In  this  paper,  we  describe  one  such  tool  — the  AUGMENT  precompiler  for 
FORTRAN  ([7])  — and  illustrate  a design  philosophy  which  has  proved  to  be  a 
reasonable  application  of  the  above  criteria.  Briefly,  we  advocate  the  ab- 
straction of  the  data  type  representations  to  the  maximum  possible  degree  in 
the  design  and  Implementation  of  software  packages,  and  subsequent  application 
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of  the  AUGMENT  precompiler  to  bind  the  data  type  representations  and  extend 
them  throughout  the  package. 


We  illustrate  this  philosophy  with  examples  drawn  from  the  interval 
arithmetic  and  triplex  arithmetic  packages  developed  by  the  second  author. 

We  also  give  an  indication  ot  several  other  applications  of  AUGMENT 
whioh,  while  not  necessarily  employing  this  philosophy,  serve  to  indicate  the 
breadth  of  possible  applications  of  AUGMENT. 

In  Section  2,  we  desorlbe  the  AUGMENT  precompiler  briefly.  This  is  done 
for  completeness;  although  the  AUGMENT  preoompiller  is  described  extensively 
in  [7]  and  in  [5>  6],  the  present  paper  requires  that  the  reader  have  at  least 
a basic  understanding  of  what  AUGMENT  is  and  what  it  does.  In  Section  3,  we 
discuss  the  oonoept  of  abstract  data  types.  In  Section  4,  we  show  how  AUGMENT 
was  used  in  the  development  of  the  interval  arithmetic  package  and  in  Section 
5 we  Indicate  how  this  design  philosophy  has  facilitated  modifications  to  the 
interval  arithmetic  package.  In  Section  6 we  give  some  brief  examples  of  oth- 
er applications  of  AUGMENT.  Section  7 summarizes  the  paper. 
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2.  Brief  description  of  AUGMENT 

AUGMENT  is  a program  which  allows  the  easy  and  natural  use  of  nonstandard 
data  types  in  Fortran.  With  only  a couple  of  exceptions,  it  places  nonstan- 
dard types  on  the  same  basis  as  standard  types  and  allows  the  user  to  concen- 
trate on  his  application  rather  than  on  the  details  of  the  data  type  implemen- 
tation. 

AUGMENT  gains  its  power  and  ease  of  use  through  several  aspects  of  its 
design . 

(1)  Its  input  language  is  very  much  like  FORTRAN.  The  only  changes  are  the 
addition  of  new  type  names  and  operators,  and  the  ability  to  define  "func- 
tions" naming  parts  ("fields")  of  variables  which  may  appear  on  either  side  of 
the  assignment  operator.  Thus  it  is  very  easy  to  use — much  easier  than  learn- 
ing the  calling  sequences  of  a package  of  subroutines. 

(2)  AUGMENT  is  extremely  portable.  Since  it  is  written  in  FORTRAN,  AUGMENT 
can  be  implemented  on  almost  any  computer  (this  should  be  qualified  by  saying 
that  adequate  memory  must  be  available— one  attempt  to  implement  AUGMENT  on  a 
DEC  PDP-1 1 was  unsuccessful  because  of  the  limited  address  space) . The 
machine-dependencies  of  AUGMENT  are  concentrated  in  eight  subroutines  which 
can  be  implemented  in  less  than  200  lines  of  (machine-dependent)  FORTRAN. 

(3)  AUGMENT'S  output  is  standard  FORTRAN  which  makes  it  suitable  as  a 
cross-precompiler;  that  is,  the  AUGMENT  translation  may  be  performed  on  one 
(large)  machine  and  the  results  compiled  on  or  for  some  other  machine  which  is 
unable  to  host  AUGMENT . This  was  the  approach  taken  when  the  interval  arith- 
metic package  was  implemented  on  the  PDP-11. 

There  are  three  major  steps  in  the  use  of  AUGMENT: 

Specification  of  the  nonstandard  data  type 

Binding  to  a representation  (implementation) 

Application 

As  is  readily  seen,  the  first  two  steps  may  be  very  easy  or  may  be  skipped  en- 
tirely in  cases  where  appropriate  research  and  development  has  already  been 
performed.  We  give  a brief  sketch  of  these  steps  below;  the  remainder  of  the 
paper  Illustrates  them  in  some  specific  cases. 

Specification.  The  whole  process  begins  with  the  specification  of  the 
properties  of  a nonstandard  type.  The  specification  will  need  to  consider  the 
following  questions: 

What  information  will  the  user  see? 

What  operations  will  be  made  available? 

How  will  this  type  interact  with  other  types? 

In  many  cases,  the  answers  to  these  questions  will  be  available  in  previous 
research  or  obvious  from  the  nature  of  the  new  type.  For  example,  a multiple 
precision  floating  point  type  should  parallel  the  standards  as  muoh  as  possi- 
ble. In  other  cases,  considerable  research  may  be  needed  and  even  an  appeal 
to  personal  preference  (there  are  at  least  two  dlstlnot  schools  of  opinion  on 
the  proper  way  to  define  comparison  in  interval  arithmetic) . 
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AUGMENT  gives  little  assistance  to  this  part  of  the  process.  The  speci- 
fications will  be  guided  by  the  applications  envisioned  by  the  person  prepar- 
ing the  new  type,  by  the  operations  known  or  felt  to  useful  in  manipulating 
the  type,  and  esthetic  considerations  such  as  consistency  with  similar  types 
(if  any)  already  existing  in  Fortran  or  previous  extensions. 

Binding  ( Implementation ) . The  binding  of  the  abstract  specification  of 
the  new  type  to  a representation  usable  through  AUGMENT  is  by  means  of  a "sup- 
porting package"  of  subroutines  and  functions,  and  through  a "description 
deck"  which  tells  AUGMENT  about  the  supporting  package.  In  this  effort,  the 
implementor  must  consider  the  conventions  expected  by  AUGMENT  in  terms  of  ar- 
gument number  and  order.  These  conventions  are  treated  at  length  in  the  AUG- 
MENT User  Documentation  [5]. 

In  addition  to  this,  there  may  remain  basic  questions  of  representation. 
For  example,  the  data  structure  which  the  user  sees  may  not  necessarily  be  the 
best  way  to  implement  the  type.  Suppose  that  the  new  type  is  specified 
abstractly  as  a linear  sorted  list  into  which  the  user  may  insert  and  retrieve 
items.  In  this  case,  it  might  be  much  more  efficient  to  implement  as  a binary 
tree  with  balancing  and  threading  properties  appropriate  to  the  expected  uses. 
The  user  might  well  remain  ignorant  of  the  underlying  implementation  and  see 
only  the  linear  sorted  list. 

Very  often  AUGMENT  can  be  used  to  assist  in  the  binding  process.  It  may 
often  be  the  case  that  only  a few  of  the  routines  in  the  supporting  package 
require  knowledge  of  the  binding.  For  example,  if  a new  arithmetic  type  (such 
as  multiple  precision)  is  being  implemented,  then  only  the  basic  arithmetic 
and  conversion  routines  would  require  knowledge  of  the  underlying  representa- 
tions. The  mathematical  functions  (SIN,  ABS,  etc)  could  be  written  using  AUG- 
MENT and  be  representation  independent.  This  would  make  it  easier  to 
reimplement  the  package  with,  for  example,  a different  precision.  In  fact, 
this  has  been  done  with  the  interval  arithmetic  packages  as  will  be  described 
later  in  the  paper. 

Application.  The  application  of  AUGMENT  to  preparation  of  a program 
which  uses  one  or  more  nonstandard  data  types  is  by  far  the  easiest  part  of 
the  process.  In  fact,  AUGMENT  was  designed  so  this  would  be  the  case.  Given 
that  the  supporting  package(s),  description  deck(s),  and  adequate  documenta- 
tion have  already  been  prepared,  the  use  of  the  package(s)  through  AUGMENT 
consists  of  just  four  steps: 

(1)  Write  the  program  using  the  new  operators  and  functions. 

(2)  Supply  AUGMENT  with  your  program  and  the  description  deck(s). 

(3)  Compile  AUGMENT'S  output  with  the  system  FORTRAN  compiler. 

(4)  Link-edit  and  run. 

Since  AU94ENT  checks  for  as  many  errors  as  it  can,  it  is  usually  unnecessary 
to  examine  the  FORTRAN  translation.  However,  we  suspect  that  most  users  will 
wish  to  examine  the  output  at  first  to  convince  themselves  that  AUGMENT  does 
produce  correct  code.  This  desire  would  be  expected  to  diminish  as  confidence 
grows  (after  all,  how  often  does  the  normal  user  examine  the  output  of  the 
system  compilers?). 
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3.  Abstract  data  types 

In  the  planning  of  most  computations,  we  do  not  explicitly  consider  the 
architecture  of  the  computer  that  will  be  processing  the  program  or  the  spe- 
cific representation  that  It  will  assign  to  real  numbers,  for  example.  In 
writing  the  code,  however,  most  languages  require  that  we  make  decisions  early 
In  the  coding  about  such  questions  as  precision,  data  representation,  and  so 
forth.  This  is  not  ordinarily  onerous,  since  we  are  usually  somewhat  limited 
in  our  selection  of  data  types  anyhow,  and  certain  variables  naturally  invite 
representation  as  integers,  others  as  "REAL"  variables,  and  yet  others  as  DOU- 
BLE PRECISION.  We  put  the  word  "REAL”  in  quotes  because  we  feel  that  this  is 
an  unfortunate  choice  for  reference  to  a single-precision  approximation  to 
real  nunbers. 

It  is  not  unusual  for  persons  trying  to  run  a program  written  for  a 
long-word  machine  on  a short-word  machine  to  experience  problems  related  to 
precision.  The  reason  for  this  is  that  they  have  come  to  depend  on  a large 
number  of  significant  digits,  a large  exponent  range,  or  both;  the  algorithm 
taxes  the  ability  of  the  short-word  machine  to  handle  the  problem.  In  such 
cases,  the  programmer  is  not  really  interested  in  what  the  data  type  is 
called,  so  long  as  it  is  an  accurate  approximation  to  the  abstract  mathemati- 
cal system  to  produce  valid  results.  Nevertheless,  the  user  caught  in  such  a 
squeeze  must  usually  declare  all  of  the  former  "REAL"  variables  to  be  DOUBLE 
PRECISION. 

AUGMENT  has  a feature  which  will  aid  a person  caught  in  such  a trap;  it 
can  be  instructed  to  convert  any  REAL  variable  to  DOUBLE  PRECISION.  While 
this  feature  may  save  many  hours  of  drudgery  for  the  person  who  has  a require- 
ment for  such  direct  conversion,  it  is  only  a hint  at  what  we  have  found  to  be 
one  of  the  major  attractions  of  AUGMENT  in  writing  special-purpose  arithmetic 
packages:  the  ability  to  use  abstract  (unbound)  data  types  throughout  the  ma- 
jority of  the  programming,  binding  the  data  type  to  a specific  representation 
only  in  the  instructions  to  AUGMENT  and  in  a few  primitive  modules  of  the 
package. 

Thus,  for  example,  one  might  write  a package  using  the  data  type  ETHEREAL 
(Express  THEoretlcal  REALs  will  do,  if  you  must  have  an  expansion  for  the  ac- 
ronym) , later  instructing  AUGMENT  to  convert  ETHEREAL  to  REAL,  DOUBLE  PRECI- 
SION, MULTIPLE  PRECISION,  or  what  have  you.  Other  data  types  may  then  be  de- 
fined as  vectors  or  matrices  of  ETHEREAL  numbers,  and  AUGMENT  will  be  able  to 
allocate  the  proper  amomt  of  space  when  it  knows  the  binding  of  ETHEREAL. 
Moreover,  the  routines  which  manipulate  the  arrays  of  ETHEREAL  numbers  may  all 
be  written  in  terms  of  operations  on  ETHEREAL  numbers;  again,  AUGMENT  will  put 
everything  right  at  precompile  time. 

The  following  sections  will  illustrate  this  philosophy  with  concrete  ex- 
amples. 
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4.  The  use  of  AUGMENT  in  the  construction  of  the  INTERVAL  package 

The  Interval  Arithmetic  Package  described  in  [18]  was  motivated  by  inter- 
est in  interval  arithmetic  on  the  part  of  several  other  universities  with  dif- 
ferent computer  systems.  This  interest  was  sparked  by  a project  sponsored  by 
the  U.  S.  Army  Corps  of  Qigineers  Waterways  Experiment  Station,  Vicksburg, 
Mississippi;  this  project  inoluded  implementation  of  interval  arithmetic  on 
various  computer  systems  and  comparison  of  the  performance  of  the  various  sys- 
tems. 


The  previous  interval  arithmetic  package  at  the  Mathematics  Research  Cen- 
ter [12]  had  been  developed  in  the  early  1970's,  and  was  quite  dependent  on 
the  UNIVAC  1100  series  architecture.  Extensive  reprogramming  would  have  been 
necessary  for  each  new  system,  and  it  was  therefore  decided  to  rewrite  the 
package  for  greater  portability. 

The  revised  package  needed  to  be  flexible  enough  to  accommodate  a wide 
variety  of  different  computer  architectures;  indeed,  since  we  wished  to  make 
the  package  adaptable  to  nearly  any  host  environment,  we  wanted  to  leave  the 
representation  of  Intervals  and  interval  endpoints  arbitrary  throughout  the 
bulk  of  the  package.  But  because  of  FORTRAN'S  popularity  for  scientific  com- 
putation, it  was  the  language  of  choice  for  implementing  the  package.  Need- 
less to  say,  ANSI  standard  FORTRAN  does  not  have  the  flexibility  we  needed  in 
order  to  accomplish  the  goals  we  had  set. 

We  wanted  to  make  the  interval  arithmetic  package  easily  accessible  from 
the  user's  point  of  view.  This  naturally  led  us  to  design  the  package  to  be 
Interfaced  with  AUGMENT:  indeed,  this  had  been  done  also  with  the  previous 
interval  arithmetic  package.  But  the  requirements  for  flexibility  and  trans- 
portability led  us  to  conclude  that  the  package  itself  should  be  written  with 
the  aid  of  AUGMENT. 

Before  we  discuss  the  role  of  AUGMENT  in  the  implementation  of  the  pack- 
age, it  would  be  appropriate  to  include  a very  brief  description  of  interval 
arithmetic.  The  Interested  reader  can  find  more  details  in  [18]  or  [11]. 

Interval  arithmetic  is  a means  for  bounding  the  error  in  computation  by 
calculating  with  pairs  of  real  numbers,  the  first  member  of  the  pair  being  a 
lower  bound  for  the  true  result,  and  the  second  an  upper  bound.  The  founda- 
tions for  interval  mathematics  have  been  carefully  laid  by  Moore  [14],  Kulisch 
[11],  and  others,  so  interval  mathematics  is  on  firm  theoretical  ground. 
There  are  closed-form  formulae  for  evaluating  operations  and  functions  on  the 
space  of  intervals,  so  that  computation  with  intervals  is  reasonably  straight- 
forward. 

In  machine  Interval  arithmetic,  one  naturally  represents  an  interval  as  a 
pair  of  approximate  real  numbers.  One  must  then  determine  what  approximation 
is  to  be  used  for  real  mabers,  and  develop  the  necessary  software  to  evaluate 
the  mathematical  functions  on  these  representations  of  real  numbers.  In  most 
cases,  the  existing  hardware/software  systems  are  not  adequate,  for  one  impor- 
tant reason:  in  order  to  preserve  the  Integrity  of  the  interval,  calculations 
involving  the  lower  bound,  or  left  endpoint  of  the  interval,  must  be  rounded 
downward;  those  involving  the  upper  bound  (right  endpoint)  must  be  rounded  up- 
ward. No  production  system  that  we  know  of  provides  these  roundings. 
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Thus,  in  designing  this  package,  we  were  fhced  with  two  problems:  defi- 
nition of  an  appropriate  system  of  real  arithmetic  approximation,  and  defini- 
tion of  the  interval  arithmetic  operations  based  on  that  approximate  real 
arithmetic  system. 

The  design  of  the  arithmetic  primitives  for  the  approximate  real  arithme- 
tic was  relatively  straightforward;  we  used  the  algorithms  given  in  [17].  The 
special  functions  posed  more  of  a problem:  straightforward  evaluation  of 
these  functions  can  lead  to  unacceptably  wide  intervals.  We  decided  to  evalu- 
ate these  functions  in  higher  precision,  and  use  Information  about  the 
inherent  error  in  the  higher  precision  procedures  before  rounding  the  results 
in  the  proper  direction  to  obtain  the  desired  real  approximation. 

In  order  to  preserve  the  desired  degree  of  flexibility,  we  introduced  the 
nonstandard  data  type  EXTENDED  to  designate  the  higher-precision  functions, 
and  the  nonstandard  data  type  BPA  (mnemonic  for  Best  Possible  Answer)  to  des- 
ignate the  approximation  to  real  numbers  used  for  the  interval  endpoints.  The 
nonstandard  data  type  INTERVAL  was  then  declared  to  be  a BPA  array  of  length 
2. 


The  BPA  portion  of  the  package  was  then  written  in  terms  of  BPA  and  EX- 
TENDED data  types  wherever  possible.  In  only  a few  cases  was  it  necessary  to 
bind  BPA  to  a standard  data  type  in  the  package  modules:  such  functions  as 
the  replacement  operator  obviously  need  to  be  bound  to  a standard  data  type  to 
avoid  recursive  calls.  There  were  sixteen  (out  of  47)  modules  in  this  portion 
of  the  package  that  seemed  to  require  such  binding. 

We  illustrate  the  implementation  of  the  BPA  portion  of  the  package  with 
the  BPA  square  root  routine.  The  COMMON  block  BPACOM  is  used  to  communicate 
the  desired  rounding  option  to  the  BPA  routine  and  to  communicate  any  errors 
(via  the  variable  BPAFLT)  to  the  calling  routine.  ACC  is  an  integer  variable 
which  indicates  the  number  of  accurate  digits  in  the  EXTENDED  routines.  The 
statement  R = ER  implicitly  invokes  the  conversion  from  EXTENDED  to  BPA,  which 
includes  addition  or  subtraction  of  an  appropriate  error  bound  and  rounding  in 
the  specified  direction. 


C 

C 

C 


SUBROUTINE  BPASQT(A,  R) 

R = SQRT(A) 

NO  ERRORS  POSSIBLE  EXCEPT  SQUARE  ROOT  OF  A NEGATIVE  NUMBER, 
WHICH  RESULTS  IN  BPAFLT  BEING  SET  TO  18 
COMMON  /BPACOM/  OPTION,  BPAFLT,  ACC,  RDU,  RDL,  RDT,  RDN,  RDA 
INTEGER  OPTION,  BPAFLT,  ACC,  RDU,  RDL,  RDT,  RDN,  RDA 
COMMON  /BPACON/  ZRO,  ONE,  01*1,  TWO,  PI02,  PI,  BPAMNB,  BPAMXB 
BPA  ZRO,  ONE,  ONM,  TWO,  PI02,  PI,  BPAMNB,  BPAMXB 

COMMON  /BPAACC/  IACC(24) , LNACC,  LGACC , SNHACC,  TNHACC,  EXPMXA, 

1 EXPMNA , FRACBD , MAXINT 

INTEGER  I ACC 

BPA  LNACC,  LGACC,  SNHACC,  TNHACC,  EXPMXA,  EXPMNA,  FRACBD,  MAXINT 

BPA  A,  R 

EXTENDED  EA,  ER 

IF( A .LT.  ZRO)  GO  TO  900 

EA  s A 

ER  = SQRT(EA) 

ACC  = IACC(50) 

R = ER 
RETURN 


BPA 10320 
BPA 10330 
BPA 10340 
BPA10350 
BPA 10360 
BPA 10370 
BPA 10380 
BPA 10390 
BPA 104 00 
BPA  104 10 
BPA 10420 
BPA 10430 
BPA 10440 
BPA 104 50 
BPA 10460 
BPA 10470 
BPA 10480 
BPA 10490 
BPA10500 
BPA10510 


900  BPAFLT  = 18 
RETURN 
END 


BPA 10520 
BPA10530 
BPA 10540 


The  INTERVAL  portion  of  the  package  was  then  written  in  terms  of  INTER- 
VAL, BPA,  and  EXTENDED  data  types.  In  this  portion  of  the  package,  only  the 
BLOCK  DATA  module,  the  error- hand ling  routine  (which  depends  on  internal  rep- 
resentation to  some  extent)  and  a routine  which  unpacks  Hollerith  strings  are 
system-dependent . 


The  following  interval  square  root  routine  illustrates  the  implementation 
of  the  interval  portion  of  the  package.  The  COMMON  block  INTCOM  is  used  for 
communication  with  the  error-handling  routine  INTRAP.  INTFLT  indicates  wheth- 
er an  error  has  occurred  and,  if  so,  its  nature;  ID  is  a code  number  designat- 
ing the  routine  which  is  calling  INTRAP;  and  TA,  TB,  and  TR  contain  the  argu- 
ments to  and  the  result  of  the  calling  routine,  respectively.  Since  the  data 
types  and  numbers  of  arguments  differ  for  different  routines,  INTRAP  is  given 
(in  another  COMMON  block)  the  information  necessary  to  decode  the  contents  of 
TA,  TB,  and  TR  properly.  Since  we  do  not  know  a priori  which  of  INTERVAL  or 
EXTENDED  may  require  the  greatest  amount  of  storage  space,  we  resort  to  the 
EQUIVALENCE  statement  to  ensure  that  enough  storage  is  allocated  for  these 
three  variables,  regardless  of  the  data  type  of  the  variables  they  may  be  re- 
quired to  contain.  Note  that  before  invoking  the  BPA  square  root  routine  (im- 
plicitly, twice;  once  for  the  right  endpoint,  or  SUP,  of  the  interval,  and 
once  for  the  left  endpoint,  or  INF,  of  the  interval),  the  variable  OPTION  is 
set  to  specify  the  desired  directed  rounding  (RDU  for  upward  directed 
rounding,  and  RDL  for  downward  directed  rounding).  After  the  computation  is 
complete,  INTFLT  is  set  to  indicate  which  faults,  if  any,  have  occurred,  the 
variable  ID  is  set  to  19  (the  code  for  the  square  root  routine),  and  INTRAP  is 
called  to  process  any  error  that  may  have  occurred.  Finally,  the  result  is 
stored  and  a return  to  the  calling  program  is  executed. 


SUBROUTINE  INTSQT( A,  R) 

C R r SQUARE  ROOT  OF  A (MONOTONE  FUNCTION) 

C THE  ONLY  FAULT  WHICH  CAN  OCCUR  IS  THE  ATTEMPT  TO  TAKE  THE 

C SQUARE  ROOT  OF  A NEGATIVE  NUMBER.  THIS  WILL  BE  DETECTED 

C IN  BPASQT. 

COMMON  /BPACOM/  OPTION,  BPAFLT,  ACC,  RDU,  RDL,  RDT,  RDN,  RDA 

INTEGER  OPTION,  BPAFLT,  ACC,  RDU,  RDL,  RDT,  RDN,  RDA 

COMMON  /INTCOM/  INTFLT,  ID,  TA,  TB,  TR 

INTEGER  INTFLT,  ID 

INTERVAL  TA,  TB,  TR 

EXTENDED  TAE,  TBE,  TRE 

EQUIVALENCE  (TA,  TAE),  (TB,  TBE),  (TR,  TRE) 

INTERVAL  A,  R 
TA  s A 

OPTION  * RDU 

SUP(TR)  = SQRT(SUP(TA) ) 

OPTION  = RDL 

INF(TR)  = SQRT(INF(TA) ) 

INTFLT  = BPAFLT 

ID  = 19 

CALL  INTRAP 

R = TR 

RETURN 

END 


INTI  8600 
INTI 86 10 
INT18620 
INT18630 
INT18640 
INT18650 
INT18660 
INT 18670 
INT18680 
INT 18690 
INT18700 
INT 187 10 
INT18720 
INT18730 
INT18740 
INT 18750 
INT 18760 
INT18770 
INT18780 
INT  18790 
INT18800 
INT 188 10 
INT18820 
INT18830 


- 8 - 


Appropriate  description  decks  were  then  prepared  for  AUGMENT,  binding  the 
nonstandard  types  EXTENDED  and  BPA  to  representations  in  terms  of  standard  da- 
ta types  (INTERVAL  remains  declared  as  a BPA  array  of  length  2).  The  entire 
package  was  then  processed  using  AUGMENT  to  extend  these  bindings  throughout 
the  package. 

In  order  to  adapt  the  resulting  package  to  a different  host  environment, 
or  different  precision,  or  both,  one  writes  the  necessary  primitive  routines, 
adjusts  the  declarations  in  the  description  deck  as  necessary,  and  reprocesses 
the  package  with  AUGMENT.  That  this  procedure  is  effective  is  attested  to  by 
the  relative  ease  with  which  this  package  was  adapted  for  use  on  the  IBM  370, 
Honeywell  600,  DEC-10,  PDP-11,  and  CDC  Cyber  systems. 


We  discuss  two  adaptations  of  the  INTERVAL  package:  the  first  of  these 
is  the  creation  of  a package  to  perform  Triplex  arithmetic,  and  the  second  is 
a package  to  perform  interval  arithmetic  in  multiple  precision. 


A.  The  TRIPLEX  package: 

Triplex  is  a variant  of  interval  arithmetic  in  which  a main,  or  "most 
probable",  value  is  carried  in  addition  to  the  endpoints.  In  West  Germany, 
which  could  be  regarded  as  the  focal  point  of  work  in  interval  mathematics, 
triplex  arithmetic  is  widely  used  in  preference  to  ordinary  interval  arithme- 
tic. 

One  of  the  visitors  at  the  Mathematics  Research  Center  was  a Professor 
fhom  the  University  of  Karlsruhe,  West  Germany,  who  wanted  to  have  access  to 
triplex  arithmetic  during  his  appointment  at  MRC.  We  decided  to  see  how  dif- 
ficult it  would  be  to  modify  the  INTERVAL  package  to  perform  triplex  arithme- 
tic. 

The  difference  between  triplex  and  interval  arithmetic  is  conceptually 
quite  simple:  at  the  same  time  one  computes  an  operation  or  function  on  the 
interval  endpoints,  using  the  Interval  mathematics  formulas,  one  evaluates  the 
same  operation  or  function  on  the  main  values,  using  standard  real  arithmetic, 
rounding  the  results  to  the  nearest  machine  number.  Assuming  that  the  real 
arithmetic  is  reasonable,  the  main  value  will  always  be  a point  in  the  inter- 
val given  by  the  endpoints. 

The  task  before  us,  then,  was  to  add  code  to  all  of  the  interval  routines 
to  compute  the  main  values,  rename  the  modules  of  the  package,  adjust  the  for- 
mats to  accommodate  the  third  value,  and,  of  course,  change  the  representation 
of  intervals  to  accommodate  the  main  value. 

The  addition  of  the  extra  code  was  straightforward  and  ordinary;  we  sim- 
ply added  the  appropriate  lines  of  code  to  each  routine  to  compute  the  main 
value.  We  should  note,  however,  that  this  did  not  disturb  the  existing  code, 
inasmuch  as  storage  and  retrieval  of  the  endpoint  values  had  already  been  de- 
fined not  in  terms  of  first  and  second  array  elements  in  the  interval  number, 
but  rather  in  terms  of  the  field  functions  INF  and  SUP  respectively  (AUGMENT 
allows  the  use  of  such  field  functions,  even  when  the  host  FORTRAN  compiler 
does  not) . 

The  modules  were  renamed  by  suitable  use  of  a text-editing  program  on 
che  INTERVAL  file.  Each  INTERVAL  routine  began  with  the  prefix  INT;  we  wanted 
the  triplex  routines  to  have  the  prefix  TPX.  We  simply  instructed  the  editor 
to  find  all  occurrences  of  INT  which  were  not  part  of  the  words  INTEGER, 
PRINT,  etc.  and  change  them  to  TPX. 

The  representation  problem  was  handled  simply  by  changing  the  word  INTER- 
VAL in  the  type  declaration  statements  to  TRIPLEX.  No  other  changes  were  nec- 
essary in  the  bulk  of  the  routines,  slnoe  AUGMENT  automatically  extended  the 
new  binding  throughout  the  package.  The  only  places  where  hand  coding  was  re- 
quired were  the  few  primitives  (such  as  the  replacement  operator)  where  we 
needed  to  handle  triples  (or  portions  of  them)  rather  than  pairs.  Again,  some 
of  these  are  obviously  necessary  to  define  basic  operations. 
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The  triplex  square  root  routine  below  illustrates  the  types  of  changes  to 

the 

interval  package  that  were  neoessary  to  produce  the  triplex  package: 

SUBROUTINE  TPXSQT(A,  R) 

TPX20050 

C 

R = SQUARE  ROOT  OP  A (MONOTONE  FUNCTION) 

TPX20060 

C 

THE  ONLY  FAULT  WHICH  CAN  OCCUR  IS  THE  ATTEMPT  TO  TAKE  THE 

TPX20070 

C 

SQUARE  ROOT  OF  A NEGATIVE  NUMBER.  THIS  WILL  BE  DETECTED 

TPX20080 

C 

IN  BPASQT. 

TPX20090 

COMMON  /BPACOM/  OPTION,  BPAFLT , ACC,  RDU,  RDL,  RDT,  RDN,  RDA 

TPX20100 

INTEGER  OPTION,  BPAFLT,  ACC,  RDU,  RDL,  RDT,  RDN,  RDA 

TPX201 10 

COMMON  /TPXCOM/  TPXFLT,  ID,  TA,  TB,  TR 

TPX20120 

INTEGER  TPXFLT,  ID 

TPX20130 

TRIPLEX  TA,  TB,  TR 

TPX20140 

EXTENDED  TAE,  TBE,  TRE 

TPX20150 

1 

r 1 

EQUIVALENCE  (TA,  TAE),  (TB,  TBE),  (TR,  TRE) 

TPX20160 

TRIPLEX  A,  R 

TPX20500 

TA  = A 

TPX20180 

' 

OPTION  = RDU 

TPX20190 

SUP(TR)  s SQRT(SUP(TA) ) 

TPX20200 

OPTION  = RDN 

TPX20210 

MAIN(TR)  = SQRT(MAIN(TA) ) 

TPX20220 

OPTION  = RDL 

TPX20230 

l 

INF(TR)  = SQRT(INF(TA)) 

TPX20240 

IF (BPAFLT  .NE.  0)  TPXFLT  = 66 

TPX20250 

ID  = 19 

TPX20260 

CALL  TPXRAP 

TPX20270 

' 

R = TR 

TPX20280 

I 

RETURN 

TPX20290 

END 

TPX20300 

Changing  the  I/O  formats  proved  to  be  more  time-consuming  and  error-prone 

> than 

all  of  the  rest  of  the  changes  put  together.  This,  however, 

was  a me- 

chanical  task. 

j 

The  modification  of  the  INTERVAL  package  to  produce  a TRIPLEX  package  was 

accomplished  in  little  more  than  one  week  of  elapsed  time,  documentation  ([1]) 

excepted.  This  measures  the  time  from  when  we  first  started  modifications  un- 

til 

we  had  obtained  a completely  successful  test  run,  performed  all 

of  the 

t housekeeping  functions,  and  had  the  package  ready  for  production  use. 

B.  The  Multiple  Precision  INTERVAL  package: 

One  of  the  goals  of  the  original  design  of  the  INTERVAL  paokage  was  to 

allow  for  increased  precision  in  cases  where  that  was  desired.  When 

the  mul- 

tiple  precision  arithmetic  package  of  Brent  [2]  became  available,  it 

was  only 

natural  to  consider  using  that  package  as  a basis  for  the  multiple 

precision 

version  of  INTERVAL. 

The  first  step  in  this  prooess  was  to  develop  an  AUGMENT  interface  for 

Brent"s  package.  This  we  did  in  collaboration  with  Brent,  and  the 

interface 

is  written  up  in  [31* 

The  steps  in  developing  the  multiple  precision  version  of  the 

Interval 

package  were:. 

1 
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1.  Determine  the  representation  to  be  used  for  the  real  approximations. 
(Brent's  package  allows  a great  deal  of  flexibility  in  this  regard.) 


2.  Write  the  primitive  arithmetic  operations,  basing  these  on  Brent's 

routines,  but  providing  direoted  roundings  (Brent's  package  does  not 
have  this  capability) . 

3.  Use  Brent's  paokage  as  the  EXTENDED  arithmetic  package. 

4.  Write  the  necessary  BPA  primitives.  The  real  format  for  BPA  numbers 

will  be  closely  related  to  the  format  of  the  Brent  multiple  preci- 
sion numbers,  but  will  have  fewer  digits  and  smaller  exponent  range. 

5.  Write  an  additional  module  whloh  will  set  the  necessary  constants 

based  on  the  run-time  precision  chosen  for  the  BPA  numbers.  This 
will  use  features  of  Brent's  package. 

6.  Rewrite  the  description  decks  as  necessary 

7.  Reprocess  the  package  with  AUGMENT. 

The  development  of  the  multiple  precision  version  of  the  interval  package 
took  somewhat  longer  than  the  development  of  the  TRIPLEX  package,  due  primari- 
ly to  the  need  to  write  the  BPA  primitives  (these  were  the  same  for  TRIPLEX  as 
for  INTERVAL)  and  the  rather  extensive  format  changes  in  the  error  handling 
routine  that  were  necessary  to  accommodate  the  flexible  representation  afford- 
ed by  Brent's  package. 


6.  Other  applicationa  of  AUGMENT 


In  the  foregoing,  we  have  illustrated  the  flexibility  that  may  be  gained 
by  using  abstract  data  types.  We  now  consider  sane  extensions  of  this  con- 
cept, and  some  other  applications  of  AUGMENT. 

a.  Recursive  data  type  definitions:  The  versatility  of  AUGMENT  may  not 
be  readily  apparent  from  the  above  examples.  AUGMENT  allows  data  types  to  be 
defined  in  terms  of  one  another,  and  this  opens  up  some  unique  possibilities. 
The  first  author  once  used  AUGMENT  to  aid  in  the  writing  of  a program  to  sort 
information  that  was  stored  in  the  form  of  trees.  Since  the  data  was 
multiply-layered,  the  values  of  one  tree's  nodes  would  often  be  other  trees. 
This  problem  was  addressed  by  creating  two  data  types:  TREE  and  NODE.  One 
field  of  a TREE  was  the  root  NODE,  and  one  field  of  a node  was  a TREE.  The 
development  of  the  program  using  these  new  data  types  was  straightforward . 

b.  Analytic  differentiation  of  FORTRAN  functions:  This  package,  de- 
scribed in  [10],  allows  one  to  obtain  the  Taylor  Series  expansion  or  the  gra- 
dient of  a function  which  can  be  expressed  as  a FORTRAN  program.  The  tech- 
nique is  shown  to  be  applicable  to  functions  defined  in  terms  of  loops  and 
conditional  expressions  as  well  as  to  the  more  conventional  case  of  functions 
defined  by  a single  FORTRAN  statement. 

c.  Dynamic  precision  calculations:  In  certain  types  of  applications, 
the  precision  required  for  the  calculations  is  a function  of  the  data.  ANSI 
standard  FORTRAN  is  not  an  appropriate  language  for  such  applications,  since 
the  precision  of  a given  variable  is  both  limited  and  predetermined.  AUGMENT 
allows  the  definition  of  data  types  which  are  lists,  however,  and  by  using 
this  feature,  precision  can  be  determined  dynamically.  One  example  of  this 
technique  is  the  dynamic  precision  package  of  Fullerton  [8];  another  is  the 
SAC-1  system  of  Collins  and  others  [4],  which  was  developed  without  the  aid  of 
AUGMENT  but  will,  if  our  information  is  correct,  soon  be  Interfaced  with  AUG- 
MENT by  another  group. 

c.  Simulations:  AUGMENT  has  been  used  to  simulate  one  computer  on  an- 
other. The  technique  for  doing  this  is  straightforward;  one  defines  a non- 
standard data  type  which  represents  the  simulated  machine,  and  prepares  a non- 
standard package  which  copies  the  arithmetic  characteristics  and  data  formats 
of  the  target  computer.  This  has  been  used  to  provide  a means  for  algorithm 
development  and  word-length  sensitivity  analysis  for  airborne  computers  prior 
to  their  production. 

e.  Algorithm  analysis:  AUGMENT  can  be  used  to  provide  information  such 
as  operation  counts  in  the  running  of  programs  or  portions  thereof.  One  sim- 
ply defines  a nonstandard  data  type  which,  in  addition  to  performing  the  stan- 
dard operation,  increments  a counter.  Such  statistics  can  be  collected  for 
entire  programs  quite  easily  by  using  the  • CONVERT  feature  of  AUGMENT,  which 
allows  one  to  oonvert  every  instance  of  one  data  type  (standard  or  nonstan- 
dard) to  another  type;  or,  by  inserting  statements  to  print  and  reset  counters 
in  the  source  oode,  one  can  analyze  specific  portions  of  the  program. 

f.  Image  prooeeslng:  The  ploture  processing  paokage  described  in  [9]  is 
probably  one  of  the  moat  unuaual  applications  of  AUGMENT  we  have  yet  seen. 
Various  new  operators  allow  the  oonatruotion  of  composite  pictures  from  small- 
er parts,  and  mathematical  functions  have  even  been  defined  on  type  PICTURE. 
For  example,  if  P is  type  PICTURE,  then  SIN(P)**2  would  yield  a contour  plot 


« 


13 


of  the  intensity  of  P,  and  (SIN(P))M4  would  yield  a contour  plot  with  sharper 
contours . 

The  above  illustrations  should  serve  to  indicate  that  the  role  of  AUGMENT 
in  developaent  of  mathematical  software  is  limited  primarily  by  the  user's  im- 
agination. 


7.  Conclusion: 


We  have  indicated  a number  of  ways  in  which  the  AUGMENT  preconpiler  for 
FORTRAN  can  be  and  has  been  used  to  aid  in  the  development  of  mathematical 
software.  Other  applications  will  undoubtedly  be  fotxid  for  this  precompiler, 
since  it  is  both  versatile  and  powerful. 

Some  of  the  emerging  languages  in  research  environments  have  some  or  per- 
haps all  of  the  capabilities  alluded  to  in  this  paper.  For  example,  CLU  [13], 
ALPHARD  [16],  and  EUCLID  [15]  are  oapable  of  handling  abstraot  data  types. 
But  at  this  writing,  such  languages  are  largely  unavailable  to  most  users. 

Perhaps  production  languages  of  the  future  will  lnolude  facilities  imple- 
menting such  techniques  as  abstraot  data  type  definition  and  dynamio  precision 
determination;  we  hope  so.  But  at  the  present  time,  AUGMENT  seems  to  be  one, 
if  not  the  only,  avenue  open  to  the  user  who  needs  this  sort  of  power  and 
flexibility  in  his  work. 
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